软件系统公司实战经验分享：手机当扫码枪小程序在MES系统中的高并发集成方案
我司深耕离散制造信息化八年，前后给三十多家规模以上工厂做过MES（制造执行系统）的落地与集成。去年夏天，我们团队接了个挺有意思的活儿——国内一家中等规模的汽车零部件制造商，找我们重构他们数据采集层。客户提的需求很“接地气”：能不能让产线工人的手机直接变成扫码枪？他们内部算过一笔账，传统工业扫码枪一把七八百块，产线加仓库少说配三百把，后续维修、折旧都是麻烦事。而工人本来就有智能手机，要是能装个小程序扫条码，硬件成本几乎归零。
这主意听起来简单，真做起来才发现水有多深。特别是高并发场景下的集成，我们前后迭代了三个版本才彻底稳住。
先说业务背景。该客户日均生产工单超两千条，物料出入库、工序报工、质量抽检全靠条码驱动。并发高峰集中在早班开工和午休结束那二十分钟，车间里上百个工人同时掏手机扫工单码和物料码，瞬时并发请求能冲到上万。原有的MES是十年前基于SOAP协议的老框架，接口吞吐量极低，根本经不起这么造。
我们最初的方案很常规：小程序扫码后，通过HTTPS接口直接调MES的REST网关。压测时模拟了5000人同时操作的场景，一出事就露馅——局域网里几百台手机同时TLS握手，网关CPU直接打满，超时一大片。工人那边看到界面转圈，习惯性地狂点重试，结果雪崩，初版错误率高达12%，主要是连接重置和数据库死锁。
后来我们痛定思痛，把架构拆成了“边缘缓冲 异步削峰”的模式。小程序端不再直接怼后端，而是先在本地用IndexedDB建了个待发队列。扫码成功先落本地存储，网络不好就暂存，信号稳了再批量上报。这里有个细节，Android和iOS的摄像头授权机制不一样，我们给扫码组件加了自适应的曝光和对焦补偿，免得工人对着条码晃半天没反应。另外，前端做了本地去重，同一码5秒内重复扫直接拦截。
通讯层我们弃用了短连接，改用了MQTT协议，通过小程序端的WebSocket桥接。服务端起了3个节点的EMQX集群，按车间和产线划分topic做分片，避免单节点热点。消息进来后先入Kafka，分区数设了32，后端消费者组慢慢消费，再转成MES能懂的报文。这样即便瞬间涌进来一万条扫码，也能在消息队列里排队，不会冲垮核心业务库。
最麻烦的是和老MES的对接。那套系统只认每小时批量的XML文件，我们只好在中间写了个适配服务，用Go写了个高并发的协议转换器，把Kafka里的JSON流攒批、映射、生成临时文件，再通过SFTP投送。为了防重复，Redis里给每个扫码事件加了唯一指纹，TTL设两小时，确保工单不会因为工人手滑扫两次而重复报工。
上线前两周试运行，还是出了幺蛾子。有天傍晚车间Wi-Fi控制器重启，几百个手机断线后按固定间隔重连，又把MQTT集群冲了。我们连夜加了指数退避算法，并且把重连抖动时间随机化，总算压下去。
现在这套方案跑了一年多，平稳支撑过单日最高140万次扫码，峰值TPS测到过1.2万，MES端数据延迟控制在三秒内。客户后来跟我们说，光扫码枪采购费就省了二十多万，更别说灵活性——临时外协工用自己手机就能入网操作。
做这行久了，总觉得技术选型别光看PPT上的架构图。手机当扫码枪这事儿，原理谁都懂，可真要融进高并发的MES血脉里，得在车间沾过灰、被工人骂过界面卡，才能打磨出靠谱的方案。如果同行有类似场景，欢迎私下交流，咱们一起少踩点坑。
（字数统计：约1150字）
微信号：18581869297
